|
|
image.png (194,264 bytes) |
|
|
Hi Jason HomeUI has been released on bitbucket Please use it and proceed with the Google test (TvtsHdmiHostTestCases) after sys.skb.resolution.nonoverride = true =============================================================== Author: kimyh <kimyh@digicaps.com> Date: Thu Jun 1 11:40:58 2023 +0900 SKB_STB_Home_UI5.0_SMART3_v1.21.0_r22616_foxconn_20230601 배포 =============================================================== Please let me know the test result Thank you YK.Jung |
|
|
Hi YK, I've applied the following commit SKB_STB_Home_UI5.0_SMART3_v1.21.0_r22616_foxconn_20230601 배포 but the result is very weird. 1. the HomeUI is enlarged. (Please refer to homeui.png) 2. Before I set sys.skb.resolution.nonoverride as true, the tvts has 11 failures, after I set sys.skb.resolution.nonoverride as true, the tvts still has 11 failures. and the failures doesn't related to DPI that Intek encountered before. Could you check it? Thanks, Jason |
|
|
Hi YK, We've fix the "The resolution of the active display mode should be either the maximal supported or the maximal supported standard 19:16 mode. Active mode" issue, I also verified it with HomeUI SKB_STB_Home_UI5.0_SMART3_v1.21.0_r22616_foxconn_20230601 배포 with sys.skb.resolution.nonoverride as true The result is pass. But when I pull the latest HomeUI, SKB_STB_Home_UI5.0_SMART3_v1.21.0_r22624_foxconn_20230601 The DPI issue happened again, (I've already set sys.skb.resolution.nonoverride as true). Please check it with Digicap. Thanks, Jason tvts.png (30,217 bytes) |
|
|
Hi Jason Thank you for checking I will deliver this status to Digicap FYI,Digicap is day-off until next Tuesday. He'll start working on Wednesday. Thank you YK.Jung |
|
|
Hi Jason I checked with Digicap and AML It is applied normally. In other words, even if you use the HomeUI below, it should pass normally after sys.skb.resolution.nonoverride as true SKB_STB_Home_UI5.0_SMART3_v1.21.0_r22624_foxconn_20230601 ( or You can use the V15.537.50 version. ) Please check it again And If you still have a failure, please send me a log and test result Thank you YK.Jung |
|
|
Hi YK, I've set the property and test it with 15.537.50. We still encounter DPI failures, Please check the attachment. Thanks Jason |
|
|
Hi YK, I use the latest launcher that Digicap commit today. this one can pass TVTS commit d5f473ce17874732cba297aab34902a48631e41f Refs: [HEAD], {m/BFX-AT100_5.3.7}, {skb_prebuilts/BFX-AT100_5.3.7} Author: kimyh <kimyh@digicaps.com> AuthorDate: Wed Jun 7 16:19:33 2023 +0900 Commit: kimyh <kimyh@digicaps.com> CommitDate: Wed Jun 7 16:19:33 2023 +0900 SKB_STB_Home_UI5.0_SMART3_v1.21.0_r22628_foxconn_20230607 배포 --- Thanks, Jason |
|
|
Hi Jason Thank you for confirming. I reported this test result to digicap and AML Thanks YK.Jung |
|
|
Hi jason In recent versions, this test result is expected to fail again. r22642 => The test result will be fail(?) at v15.537.52 FW r22628 => pass r22624 => Fail However, the test result of INTEK is being passed. It is currently occurring only in the FXN model, and INNOPIA is preparing for the test. (I will update you when I know the result of INNOPIA. ) Since INTEK has become a pass, it is expected that it may be caused by differences in implementation by manufacturer. Please let me know if there is anything else that the manufacturer needs to check. If I check the changed code on HomeUI and let you know, can you check it additionally? Thank you YK.Jung |
|
|
Hi Jason Please check attached picture. The left is the code that becomes pass and the right is the code that becomes fail at BFX-AT100 Left(r22628) : pass ( Digicap SouceCode that only handles 720p.) Right(r22624) : Fail ( Digicap SouceCode that only handles all resolutions) If Digicap use the left code here, there is a critical issue in Live channel at all manufacturer So , Currently, the right code should be used. Here, INTEK says that the TVTS test result is passed even on the right code. Is there anything you can check? Thank you YK.Jung |
|
|
Hi YK, I can not understand the difference in image-2.png. According to your request, you ask us to set sys.skb.resolution.nonoverride as true before testing. the left picture will return early by checking if resolution not equal 720p. if the resolution is equal to 720, the code still return in the nonoverride condition. the right section will always return because nonoverride is true. Both of these codes will return in the middle of this function, so I can't distinguish the difference. Thanks, Jason |
|
|
Hi Jason As I checked now, INNOPIA also said that there is no issue. This issue is only occurring on FXN. And is there anything different about this requesting function regarding EDID? or shall I ask Digicap to build a test HomeUI with only the return removed as shown in the picture below? If only the return is removed, I think it should be pass. then the function below has some effect and it looks like it's going to be pass in FXN. val resolution = STBAPIManager.getInstance().displayReoution Please let me know if you have any other opinions. Thank you YK.Jung |
|
|
Hi YK, I don't know the detail implementation of STBAPIManager.getInstance().displayReoution. It looks like's Digicap API. if STBAPIManager.getInstance().displayReoution will trigger critical issue in LiveTV but pass in Foxconn model, I think they can change the code flow as below, Because nonOverride property is workaround, the value will be false in normal mode, I think it will not impact LiveTV val nonOverride = SystemProperties..... if (nonOverride) { val resolution = STBAPIManager.getInstance().displayResolution if (STBAPIManager....) { LOG return } LOG return } Thanks, Jason |
|
|
Hi Jason Currently, HomeUI is only testable, not modifiable If this modification causes another manufacturer's failure, it is a difficult situation. Anyway , to check the cause, Could you please set it to sys.skb.resolution.nonoverride as true and attach the log for pass and fail? I think we need to clarify the difference between passed logs and failed logs r22642 => The test result will be fail(?) at v15.537.52 FW r22628 => pass Thank you YK.Jung |
|
|
Hi YK, I tested 15.537.52 today, the 1st run -> pass Do btv reset the 2nd run -> 12 dpi failure, so I feel very weird. During testing this module, the hdmi port of STB need to connect Integral2, and HDMI output of Integral2 will connect to Monitor/TV. In the first screen, I can see the resolution information on Integral2 is "720P59". (Please refer to the first.jpg) for the 1st run -> I saw the resolution information on Integral2 is 1080P60. but after btv reset, the resolution information on Integral2 change to 720P59. I don't know which resolution is correct for initial value after btv reset. Please check it with Intek. Base on this clue, I do the following steps, 1. do btv reset 2. the resolution information shows 720P59 3. use blue 7898 in IP page, and set 1080p resolution 4. the resolution information shows 1080P60 5. run tvts-cert -m TvtsHdmiHostTestCases 6. we will get 6 failure, the 6 failures do NOTcontain DPI failure 7. use blue 7898 in IP page, and set auto resolution 8. the resolution information shows 720P60 (NOT 720P59) 9. run tvts-cert -m TvtsHdmiHostTestCases again (not use retry command) 10. the resul will be all pass. I also use the r22624 to verify my steps again. we can get pass result with my test steps. Please forward the clue to Amlogic. If I have any new clue, I will update it. Thanks, Jason first.jpg (27,576 bytes) |
|
|
Hi YK, I go back to verify the certificated build (15.537.42), the default information is also 720P59, but it's old HOMEUI, so we don't have DPI failures. Thanks, Jason |
|
|
Hi Jason The INTEK manager says he doesn't know. ( I will let you know if there is a feedback. ) I'm asking AML additionally. After the resolution set auto resolution If STB set resolution to 720P60 instead of 720P59, the test result seems to be pass. I think you can fix this 15.537.42 FW is in fixed mode. So there won't be a problem. Thank you YK.Jung |
|
|
Hi YK, >>15.537.42 FW is in fixed mode. >>So there won't be a problem. Wrong, 15.537.16 is Fix mode, => Fix mode has tvts issue, so we can NOT pass TVTS. 15.537.42 is real mode. The original real mode is OK. >>If STB set resolution to 720P60 instead of 720P59, the test result seems to be pass. >>I think you can fix this I don't think so, in self-build 15.537.42 is real mode, when I test TVTS, the information on Integral2 is also 720P59. so 720P59 can also pass TVTS After Digicap modify the launcher, we have DPI issue, I still have no idea, so I provide the clue to Amlogic/Digicap to analyze it. Please check it. Thanks, Jason |
|
|
Hi Jason >> Wrong, >> 15.537.16 is Fix mode, => Fix mode has tvts issue, so we can NOT pass TVTS. >> 15.537.42 is real mode. The original real mode is OK. ah , ok I was confused because the version is the same. 15.537.42 is real mode ( FXN self-build) 15.537.42 is fixed mode ( SPTEK tag ) Now, Amlogic said that they don't know what you have provided. This issue is only occurring in the FXN model, so it is difficult to approach it as a common issue. Anyway , I will talk to Digicap again today. Please let me know if you have any other opinions. Thank you YK.Jung |
|
|
Hi jason Attached is the APK file modified by Digicap as shown in the attached picture Please test with this apk. Thank you YK.Jung image-3.png (65,042 bytes) |
|
|
Hi YK, Could you check it with Digicap, I've applied it and built the test image. After finishing the SetupWizard, the screen shows black. I can not see SKB login UI. 06-19 17:05:27.063 11874 11874 D XWalkLib: Init embedded mode 06-19 17:05:27.063 11874 11874 D XWalkLib: [Environment] SDK:31 06-19 17:05:27.063 11874 11874 D XWalkLib: [App Version] build:24.53.595.1, api:8, min_api:8 06-19 17:05:27.064 11874 11874 D XWalkLib: [Lib Version] build:24.53.595.1, api:8, min_api:5 06-19 17:05:27.065 11874 11874 D XWalkLib: Crosswalk download mode: false 06-19 17:05:27.065 11874 11874 D XWalkLib: XWalk core version matched 06-19 17:05:27.067 11874 11874 D XWalkLib: Crosswalk's xwalkcore, SDK VERSION : 31 06-19 17:05:27.070 11874 11874 D XWalkLib: java.lang.UnsatisfiedLinkError: dlopen failed: library "libxwalkcore.so" not found 06-19 17:05:27.071 11874 11874 D XWalkLib: Mismatch of CPU architecture 06-19 17:05:27.071 11874 11874 D AndroidRuntime: Shutting down VM 06-19 17:05:27.072 11874 11874 E AndroidRuntime: FATAL EXCEPTION: main 06-19 17:05:27.072 11874 11874 E AndroidRuntime: Process: com.skb.tv, PID: 11874 06-19 17:05:27.072 11874 11874 E AndroidRuntime: java.lang.RuntimeException: Unable to start activity ComponentInfo{com.skb.tv/com.skb.google.tv.main.MainActivity}: java.lang.RuntimeException: Please have your activity extend XWalkActivity for shared mode 06-19 17:05:27.072 11874 11874 E AndroidRuntime: at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3635) 06-19 17:05:27.072 11874 11874 E AndroidRuntime: at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3792) 06-19 17:05:27.072 11874 11874 E AndroidRuntime: at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:103) 06-19 17:05:27.072 11874 11874 E AndroidRuntime: at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:135) 06-19 17:05:27.072 11874 11874 E AndroidRuntime: at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:95) 06-19 17:05:27.072 11874 11874 E AndroidRuntime: at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2210) 06-19 17:05:27.072 11874 11874 E AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:106) 06-19 17:05:27.072 11874 11874 E AndroidRuntime: at android.os.Looper.loopOnce(Looper.java:201) 06-19 17:05:27.072 11874 11874 E AndroidRuntime: at android.os.Looper.loop(Looper.java:288) 06-19 17:05:27.072 11874 11874 E AndroidRuntime: at android.app.ActivityThread.main(ActivityThread.java:7839) 06-19 17:05:27.072 11874 11874 E AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method) 06-19 17:05:27.072 11874 11874 E AndroidRuntime: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548) 06-19 17:05:27.072 11874 11874 E AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1003) 06-19 17:05:27.072 11874 11874 E AndroidRuntime: Caused by: java.lang.RuntimeException: Please have your activity extend XWalkActivity for shared mode 06-19 17:05:27.072 11874 11874 E AndroidRuntime: at org.xwalk.core.XWalkCoreWrapper.initEmbeddedMode(XWalkCoreWrapper.java:214) 06-19 17:05:27.072 11874 11874 E AndroidRuntime: at org.xwalk.core.XWalkPreferences.reflectionInit(XWalkPreferences.java:280) 06-19 17:05:27.072 11874 11874 E AndroidRuntime: at org.xwalk.core.XWalkPreferences.setValue(XWalkPreferences.java:119) 06-19 17:05:27.072 11874 11874 E AndroidRuntime: at com.skb.google.tv.fullFragment.G2.G2TvFragment.initCommon(G2TvFragment.java:2370) 06-19 17:05:27.072 11874 11874 E AndroidRuntime: at com.skb.google.tv.main.MainActivity.onCreate(MainActivity.kt:1730) 06-19 17:05:27.072 11874 11874 E AndroidRuntime: at android.app.Activity.performCreate(Activity.java:8051) 06-19 17:05:27.072 11874 11874 E AndroidRuntime: at android.app.Activity.performCreate(Activity.java:8031) 06-19 17:05:27.072 11874 11874 E AndroidRuntime: at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1329) 06-19 17:05:27.072 11874 11874 E AndroidRuntime: at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3608) 06-19 17:05:27.072 11874 11874 E AndroidRuntime: ... 12 more Thanks, Jason |
|
|
Hi Jason I reported it to Digicap and Looking at the logs, the apk seems to be made for OS10. I'll let you know when I get feedback. Thank you YK.Jung |
|
|
Hi Jason I received it again from Digicap. Please use the apk attached. Thank you YK.Jung |
|
|
Hi YK, I've verified the SKB_STB_Home_UI5.0_SMART3_v1.21.0_r22647_foxconn_20230619.zip. We still have DPI failure, it's very weird. >>The INTEK manager says he doesn't know. ( I will let you know if there is a feedback. ) Have you checked it? I suspect there are some settings in uboot environment that will impact resolution and test result? Could you check it with Amloigc? Thanks, Jason |
|
|
Hi Jason >> We still have DPI failure, it's very weird. You set sys.skb.resolution.nonoverride to true and tested, is it correct? >>>>The INTEK manager says he doesn't know. ( I will let you know if there is a feedback. ) >> Have you checked it? In the case of INTEK, there is no information on how this issue was fixed because it did not occur. >>I suspect there are some settings in uboot environment that will impact resolution and test result? >> Could you check it with Amloigc? Please let me know in detail which environment settings of uboot is suspicious. This issue must be resolved by this week. Thank you YK.Jung |
|
|
Hi Jason >> We still have DPI failure, it's very weird. You set sys.skb.resolution.nonoverride to true and tested, is it correct? yes, I already set it. >>>>The INTEK manager says he doesn't know. ( I will let you know if there is a feedback. ) >> Have you checked it? >>In the case of INTEK, there is no information on how this issue was fixed because it did not occur. I want to check the information when they pass. >>I suspect there are some settings in uboot environment that will impact resolution and test result? >> Could you check it with Amloigc? Please let me know in detail which environment settings of uboot is suspicious. The result is same as 15.536.52 use OTA (with wipe data) to udpate FW then run the 1st run -> pass, I think at this moment, the /data is clear, but the /btv_home and uboot environment is unknown. Do btv reset, clear /btv_home and /data the 2nd run -> 12 dpi failure, so I suspect some values in /btv_home or uboot environment may impact the test result. Could you help us check whit Digicap when will the function adjustDispaly be called? Thanks, Jason |
|
|
Hi YK, I can pass this module stably now. In previous test (without problematic launcher), we can connect the Integral2 in any time before testing TVTS. the results are always pass. According to your comment, The root cause needs to be solved in AML, but it seems difficult to fix it within the schedule, so Digicap provided the property to workaround it. In previous test, if we boot device with connecting Integral2, then setup the environment (1. enable usb adb, 2 enable passthrough, 3 setprop sys.skb.resolution.nonoverride as true), we still can see DPI failures. In today's test, I found we MUST setup the environment first, then connect to Integral2. so that we can pass this module stably. I think the timing that the function adjustDispaly be called will impact the test result. I've verified the 15.537.52 more than 5 times, the result is attached. Our QA also verified my test steps, they can get the pass result on their side. Anyway, I think the AML/Digicap will fix DPI failure before the official certification on 3PL side. because setprop is not allowed for 3PL unless we can convince it (e.g. skip skb network checking on non-Korean network environment) Before the official certification on 3PL side, we will notice the setup sequence in self test. Thanks, Jason 15.537.52.png (26,647 bytes) |
|
|
Hi YK, During testing on 15.537.42, we found the failures in the attachment. After setprop sys.skb.resolution.nonoverride as true, we can pass it. Please remember to remind AML/Digicap fix this DPI failure before the next official certification on 3PL side. Thanks, Jason CtsWindowManagerDeviceTestCases.png (21,216 bytes) |
|
|
Hi YK, The mode switching (real/fix) function has been implemented. I think we can close this issue. Thanks, Jason |
|
|
Hi Jason Thank you for your support I will close this ticket Thank you YK.JUng |
- yk.jung ( (ALTech) Younkwang Jung ) developer
.png)
.png)
.png){kind=link}
